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Résumé 

Modifier les portions fonctionnelles et non-fonctionnelles des applications au cours de leur exécution est utile 
et parfois critique tant lors des phases de développement que de suivi en production. JooFlux est un agent 
JVM qui permet à la fois de remplacer dynamiquement des implémentations de méthodes que d'appliquer des 
aspects. Il fonctionne en opérant des transformations de bytecode pour tirer parti de la nouvelle instruction 
invokedynamic apparue dans Java SE 7 pour faciliter l'implémentation de langages dynamiques au-dessus 
de la JVM. JooFlux peut être piloté à l'aide d'un agent JMX afin de conduire les modifications à l'exécution, et ce, 
sans s'appuyer sur un langage dédié. Nous avons comparé JooFlux à d'autres plates-formes d' AOP et des langages 
dynamiques. Les résultats montrent que les performances de JooFlux sont proches de celles du code Java non 
modifié. Le sur-coût est généralement négligeable, et nous observons même parfois de légers gains, tandis que les 
plates-formes d' AOP et langages dynamiques montrent des performances significativement dégradées. Ceci ouvre 
de prometteuses perspectives tant pour les évolutions futures de JooFlux que pour des études de cas. 

Mots-clés : JVM, patch à l'exécution, AOP, invokedynamic, bytecode 



1. Introduction 

La plupart des applications sont - jusqu'à un certain point - statiques. Cela est particulièrement vrai pour les 
applications développées en utilisant des langages statiquement typés. Les langages typés dynamiquement offrent 
souvent la possibilité de remplacement de méthodes pendant l'exécution, mais ces changements n'interviennent 
que depuis le programme lui-même et rarement d'outils externes. Très peu de langages offrent cet accès extérieur, 
même les langages purement fonctionnels avec un shell interactif. 

Les modifications à chaud de code ont pourtant de nombreuses et intéressantes vertus [7, 9|. Pendant les phases 
de développement, un temps important est passé et perdu à redémarrer les applications pour observer les effets des 
modifications du code source. En production, l'application de correctifs d'erreurs ou de sécurité requiert des redé- 
marrages. Un redémarrage complet peut prendre plusieurs minutes pour être opérationnel quand, dans de nombreux 
cas, une simple correction consiste juste à remplacer l'implémentation d'une méthode sans introduire d'effets de 
bord comme un changement de signature. L'ajout et le retrait dynamiques de fonctionnalités transversales, comme 
des aspects de sécurité ou de trace, peuvent également être très utiles pour capturer ou surveiller ponctuellement 
certains comportements de l'application. 

Dans le cas d'environnements adaptatifs d'exécution comme la machine virtuelle Java (JVM), ces changements 
dynamiques impliquent malheureusement la perte des optimisations effectuées - optimisations qui ne peuvent être 
obtenues et stabilisées qu'après une longue exécution - conduisant donc à une dégradation des performances. 

Notre proposition 

Cet article décrit une nouvelle approche pour modifier "à chaud" des méthodes et injecter des aspects pendant 
l'exécution d'applications Java. Nos contributions s'articulent comme suit : 

1. Nous avons conçu et développé un agent Java qui intercepte et modifie le bytecode pendant l'exécution pour 
remplacer toutes les invocations de méthodes par le nouvel opcode invokedynamic introduit dans Java 7. 
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2. Nous proposons une API de contrôle accessible par un agent JMX qui permet de gérer ces modifications 
pendant l'exécution et ce pour pouvoir se dispenser d'un langage dédié ou d'insertion d'annotations ou de 
points de coupe dans le code source. 

3. Nous présentons une comparaison entre notre prototype JooFlux et plusieurs plates-formes à aspect et lan- 
gages dynamiques existants. Les résultats mettent en exergue que les performances de JooFlux sont proches 
de celles de Java - avec un coût marginal et même quelques fois un gain - tandis que les plates-formes à 
aspects et langages dynamiques présentent des sur-coûts importants. 

Cet article est structuré avec en premier le contexte AOP, JVM et le nouvel opcode invokedynamic. Nous 
proposons ensuite JooFlux, son architecture et son fonctionnement avant de donner une comparaison de ses per- 
formances. Après un bref état de l'art, nous concluons et donnons des perspectives à ces travaux. 

2. Contexte 

Cette section comporte 3 parties. Nous commençons par quelques rappels informels sur la programmation orientée- 
aspects. Nous faisons de même avec un aperçu de la machine virtuelle Java. Enfin, nous nous focalisons sur une 
évolution de Java SE 7 qui est au cœur de notre approche, et dont l'origine est dans l'amélioration du support de 
langages dynamiques sur la JVM. 

2.1. Programmation orientée-aspects 

La programmation orientée-aspects (AOP) vise la modularisation des logiques applicatives transversales, le plus 
souvent non fonctionnelles, telles la sécurité, la validation, les transactions ou encore l'audit de traces. En effet, 
le code correspondant doit souvent être répété sur différentes couches applicatives, ce qui augmente le coût de 
maintenance. Aussi, le code fonctionnel se retrouve alors mêlé au code non fonctionnel. 
L AOP apporte une possible réponse à ses problèmes : 

1. un aspect capture une logique applicative transversale en une unique unité de code, et 

2. un point de coupe spécifie un ensemble de points de code exécutable, et 

3. un conseil matérialise l'application de l'aspect au point de coupe. 

Supposons que l'on souhaite tracer chaque invocation d'un accesseur des classes du paquet f oo. Un aspect est 
alors le code de trace. Le point de coupe correspond aux appels des méthodes publiques des classes de f oo dont 
le nom commence par get. L'application de l'aspect se fait avec un tisseur de code, qui insère alors l'aspect aux 
points de coupe concordants. 

2.2. La machine virtuelle Java 

La spécification de la machine virtuelle Java (JVM) est restée stable au cours des versions successives de la plate- 
forme fl2l . Une JVM consomme du bytecode qui est classiquement stocké dans des fichiers .cl as s et qui 
correspondent chacun à une classe Java compilée. Le format de ces classes compilées reflète la définition des 
classes dans le langage source, à savoir que chaque . class contient une seule classe, ses attributs et ses méthodes. 
On trouve également un constant pool qui correspond à un ensemble indexé de valeurs constantes qui peuvent être 
référencées depuis le reste du bytecode. Ceci permet de réduire l'empreinte mémoire des classes en évitant des 
redondances, par exemple pour se référer à des chaînes de caractères. Le modèle d'exécution de la JVM s'appuie 
sur une pile. Des opcodes permettent de la manipuler en consommant des opérandes puis poussant des résultats. 
Même si le format du bytecode Java a été conçu de façon très proche de la structure du langage de programmation 
éponyme, il demeure néanmoins un bytecode généraliste. Il est strictement plus expressif que le langage source, 
ce qui a été exploité par des outils comme des ofuscateurs Q. La JVM ne se limite pas à l'exécution d'applicatifs 
écrits en Java. Il existe un écosystème très actif de langages s'exécutant sur la JVM. Ceci inclut tant le portage 
de langages déjà existants (JRuby, Jython, Rhino) que de langages originaux (Groovy, Scala, Clojure). De nom- 
breux travaux d'optimisation des performances de la JVM couplés à une validation industrielle à large échelle 
font de cette dernière une cible très intéressante pour des langages à la recherche d'un environnement d'exécution 
performant fl4l[Tïll8l. 

2.3. Java SE 7 et invokedynamic 

La spécification de la JVM offrait 4 opcodes pour invoquer des méthodes jusqu'à la version 7. invokestatic 
est utilisé pour les méthodes statiques, invokevirtual est utilisé pour effectuer un appel en fonction du type de 
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l'objet receveur, ce qui correspond aux méthodes publiques et protégées et qui peuvent être surchargées dans des 
sous-classes, invokespecial sert aux appels directs où le type est spécifié dans la signature, soit les construc- 
teurs et méthodes privées. Enfin, invokeinterf ace fait un appel par rapport à une définition d'interface. Ce 
jeu d'opcodes est resté stable jusqu'à Java SE 7 qui a introduit invokedynamic |[T9ll . 

Un nouvel opcode 

L'objectif principal de ce nouvel opcode d'invocation de méthode est de faciliter l'implémentation de langages 
dynamiques sur la JVM. En effet, les implémentations de ces langages résolvent souvent les types, symboles et 
cibles d'appel à l'exécution. Avec les opcodes antérieurs, les implémenteurs de langages dynamiques devaient se 
tourner vers de la réflexivité et des proxys dynamiques pour déferrer ces actions à l'exécution. L'impact sur les 
performances est significatif, et les optimisations adaptatives (JIT) des machines virtuelles avaient le plus souvent 
du mal à s'appliquer sur ces constructions. 

invokedynamic est très proche de invokeinterf ace et invokevirtual dans le sens où le choix de 
l'implémentation de méthode à exécuter se fait à l'exécution. Cependant ces 2 dernières font ce choix en fonction 
d'un receveur qui est l'objet dont la définition de classe possède ladite méthode, soit en surcharge locale ou via la 
hiérarchie d'héritage, invokedynamic relâche ces contraintes et se rapproche de pointeurs de fonctions comme 
en C. Plus spécifiquement, un appel avec l'opcode invokedynamic se définit comme suit : 

1. un nom symbolique pour désigner l'invocation, et 

2. une signature pour les paramètres et le type de retour, et 

3. une instruction d'initialisation qui est invoquée lors du premier passage sur le site d'appel de l'invocation. 
Une API pour la liaison dynamique de sites d'appels 

Le rôle de l'instruction d'initialisation est de lier le site d'appel avec une cible. Pour se faire, une nouvelle API a 
été définie dans le package java . lang . invoke. Elle fournit en particulier 2 types clé. CallSite représente 
un site d'appel. Il pointe vers une instance de MethodHandle qui est soit une référence directe sur une méthode 
de classe ou attribut, soit une chaîne de combinateurs [ 19|. Voici un exemple d'utilisation de cette API : 



public static MethodHandle replaceSpaces (Lookup lookup) throws Throwable { 
return insert Argument s ( lookup . f indVirtual (String.class, "replaceAll " , 
methodType (Str ing . class , String.class, String.class)), 1, "%20", " "); 

î 

public static void main ( String . . . args) throws Throwable { 
MethodHandle mh = replaceSpaces ( lookup ()) ; 

System. out .println ( (String) mh . invokeExact ( "A%2 0B%20C%2 " ) ) ; 

} 



Il illustre comment obtenir une référence de méthode sur String. replaceAll (String, String) . En- 
suite, il utilise le combinateur insertArguments pour pré-lier certains arguments à des valeurs constantes. 
Ici, nous lions les 2 arguments de sorte que l'invocation remplace les occurrences de "%20" par " ". Comme 
la méthode est virtuelle, l'argument d'index est le receveur. L'invocation finale sur la chaîne d'exemple donne 
bien un affichage de "A B C". Un plus large panel de combinateurs est proposé afin de faire des transformations 
et adaptations depuis une cible d'appel vers une cible effective. Nous verrons plus loin une mise en pratique pour 
mettre en oeuvre des fonctionnalités de JooFlux. 

Le lien entre un site d'appel invokedynamic et l'appel d'initialisation est fréquemment fait à l'aide d'une 
méthode statique qui construit une référence de méthode dont le type direct ou transformé correspond au site 
d'appel, et enfin retourne une instance de CallSite. Ceci est illustré par la Figure [T] L'instance de CallSite 
reste constante pour un site d'appel donné. En revanche, sa cible de référence de méthode peut changer. 
Une des améliorations principales avec invokedynamic est que les chaînes de combinateurs sont liées à des 
sites d'appels clairement identifiés et qui ont des branchements internes dans la JVM. De la sorte, des optimisations 
se mettent en place plus efficacement qu'avec les approches classiques basées sur la réflexivité [21|. Enfin, la 
vérification de type ne se fait qu'à la création d'une référence de méthode et/ou d'un combinateur, à l'inverse de la 
réflexivité classique où cela doit être fait pour chaque appel. Ceci aide à l'amélioration des performances. 



ComPAS'2013 : RenPar'21/ SympA' 15/ CFSE'9 
Grenoble, France, du 16 au 18 janvier 2013 



(...) 

Idc "A%20B%20C" 

invokedynamic replaceSpaces : (Ljava/lang/String; )Ljava/lang/String; 

bootstrap -> invokestatic Indyl. bootst rap( . . . ) 

(...) 



MethodHandle 
1 



(...) 



MethodHandle 



public static CallSite bootstrap(Lookup lookup, String name, 
MethodType type) throws Throwable { 
return new ConstantCallSitet replaceSpaces ( lookup) ) ; 



Call 
Site 



Target 



Combinators: 
asType( ) 
asCollector( ) 
dropArguments( ) 
guardWithTest( ) 
(...) 



MethodHandle 



Figure 1 - Initialisation d'un site d'appel invokedynamic. 

3. JooFlux 

Cette section comporte les détails techniques du fonctionnement de JooFlux. Nous expliquons comment une indi- 
rection lors des appels de méthodes est introduite à l'aide de transformation de bytecode et de invokedynamic. 
Nous expliquons ensuite comment les aspects peuvent être attachés aux méthodes. Enfin nous présentons l'inter- 
face de gestion de JooFlux. 



3.1. Introduction d'une indirection 

JooFlux introduit une indirection sur les appels de méthode, de sorte que le remplacement de méthode et l'ap- 
plication d'aspects puisse se faire à l'exécution. Si JooFlux cible principalement le bytecode émis par un compi- 
lateur pour le langage Java, il peut théoriquement s'appliquer sur n'importe quel bytecode valide produit par un 
langage autre que Java sur la JVM tel Scala ITÏ31 . Le fait de pouvoir modifier les références de méthodes avec 
invokedynamic avec de nouvelles chaînes de combinateurs permet de changer les implémentations de mé- 
thodes. Le jeu de combinateurs disponibles nous permet également de greffer des traitements supplémentaires pré 
et post invocation sur les arguments et valeurs de retour. Nous allons voir que ceci nous permet de faire de la pro- 
grammation par aspects. Il est possible d'attacher des agents à une JVM. Ils ont la possibilité d'effectuer diverses 
opérations dont l'interception et transformation de bytecode au moment où il va être chargé dans la JVM. 



Original bytecode 



(...) 

bipush 40 

invokestatic java/lang/Integer.valueOf : (DLjava/lang/Integer; 

invokestatic fib: (Ljava/lang/Integer; )Ljava/lang/Integer; 
(...) 



Modified bytecode 



: 



JooFlux bytecode transformation 



(...) 

bipush 40 
invokedynamic 

invokedynamic 

(...) 



" java/lang/Integer. valueOf" : ( I) Ljava/lang/Integer; 

invokestatic Bootst rap.dynvokeStatic: ( . . . )L/java/lang/invoke/CallSite; ( 
"fib" : (Ljava/lang/Integer; ) Ljava/lang/Integer; 

invokestatic Bootst rap.dynvokeStatic: ( . . . )L/java/lang/invoke/CallSite; ( 




Target classes 



method_1 



Figure 2 - Aperçu de l'agent JooFlux pour la JVM. 
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La Figure [2] donne un aperçu du fonctionnement de JooFlux en tant qu'agent JVM. Il cherche les occurrences de 
invokestatic, invokevirtual, invokespecial ou invokeinterf ace puis les remplace par une 
construction sémantiquement équivalente basée sur invokedynamic. Les sites d'appels sont liés à une réfé- 
rence de méthode au moment de l'exécution. Les transformations de bytecode s'opèrent à l'aide de la bibliothèque 
ASMQ Initialement, les sites d'appels sont liés à des références de méthodes pointant sur les méthodes des classes 
originelles. Ainsi pour un invokestatic dans le bytecode, un remplacement est fait avec invokedynamic 
et un nom symbolique basé sur la signature de l'instruction invokestatic remplacée. Ceci permet d'avoir un 
schéma de nommage uniforme. Le type de l'invocation originelle est également préservée. Coté JooFlux, l'ini- 
tialisation de sites d'appels se fait via un jeu de méthodes statiques spécialisées en fonction du type d'invocation 
initiale. Ceci introduit une couche d'indirection fine. 

3.2. Aspects via des combinateurs de références de méthodes 

Une fois les classes transformées par JooFlux et chargées dans la machine virtuelle, JooFlux n'effectue plus de mo- 
difications de bytecode. L'injection se fait au niveau des chaines de combinateurs référencées par les sites d'appels. 
JooFlux utilise 2 combinateurs que l'on trouve dans la classe java . lang . invoke . MethodHandles : 

1. f ilterArguments prend pour argument une référence de méthode cible, un index d'argument et un 
tableau de références de méthodes à utiliser en filtres, et 

2. filterReturn Value prend pour argument une référence de méthode cible et une référence de méthode 
filtre. 

Les types des références de méthodes filtres doivent correspondre à ceux des méthodes cibles. Dans notre cas nous 
avons choisi une approche générique pour qu'un aspect soit agnostique de la signature de la méthode interceptée. 
Dans le cas des appels de méthode les arguments sont capturés dans un tableau d'objets, et dans le cas des retours 
un objet est employé. La classe d'exemple suivante peut être utilisée pour obtenir des traces sur des appels de 
méthodes : 



public class Dumpers { 




public static Object[] onCall (Object 


[] args) { 


Sy stem . out . pr intln ( " >>> " + Arrays 


toString (args ) ) ; 


return args; 




} 

public static Object onReturn (Object 


retval) { 


Sy stem . out . pr intln (" <<< " + retval 




return retval; 

} 

} 





Plus généralement, les aspects peuvent faire d'autres choses comme lever une exception si un argument ne respecte 
pas une pré-condition. Étant donné qu'ils agissent comme des filtres, ils peuvent aussi modifier les arguments avant 
de les passer à la méthode cible ainsi que modifier la valeur de retour. Les aspects peuvent être empilés sur un même 
site d'appel. Par exemple, il est possible d'empiler des aspects de validation et de trace. Ce qu'un aspect peut faire 
dépend aussi du type d'invocation originelle. En effet, dans le cas d'une invocation statique les arguments sont 
ceux de la méthode. En revanche pour les autres types d'invocation le premier argument est le receveur, autrement 
dit l'objet sur lequel la méthode est invoquée. 

Enfin, nous avions mentionné que les types des méthodes filtres doivent concorder avec ceux des méthodes 
cibles. Dans notre cas nous devons effectuer des adaptations pour aller vers des types génériques. Nous utili- 
sons pour cela 2 combinateurs. Le premier est asSpreader qui collecte des arguments dans un tableau. Le 
deuxième, asCollector, effectue l'opération inverse pour distribuer les valeurs d'un tableau vers des para- 
mètres. Dans notre cas, nous convertissons les arguments d'une méthode vers un tableau de type Object [] 
avec asSpreader. Celui-ci est passé au filtre, invoquant donc le conseil de l'aspect. Ensuite nous utilisons 
asCollector pour réadapter vers la méthode cible originale. La gestion de l'interception des retours de mé- 
thode est plus simple et se résume juste à passer d'un type spécifique à Object pour le conseil, puis à raffiner 
le type vers celui d'origine. Ces adaptations de type se font avec le combinateur asType et permettent de rendre 
cohérents les types sur une chaîne de combinateurs. 



1. ASM 4.0 : http: //asm.ow2 .org/ 
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3.3. Gestion des sites d'appel 

Les sites d'appel sont mis dans un registre central lors de leur création. Le registre a pour seul rôle de garder une 
référence sur les sites d'appel, et ce, afin de pouvoir ultérieurement les modifier pour appliquer un aspect. En re- 
vanche, chaque site d'appel est bien initialisé lors de la première invocation de son instruction invokedynamic, 
et les appels suivants sont directement résolus via la chaine de combinateurs associée. Par conséquent, le registre 
n'intervient pas lors des appels de méthode et ne possède pas de coût intrinsèque sur les performances des appels 
de méthodes. 

Il existe deux types de sites d'appels offerts par java . lang . invoke dont la cible puisse changer en cours 
d'exécution : MutableCallSite et VolatileCallSite. Leur sémantique correspond respectivement à un 
attribut de classe normal et à un attribut de classe volatile tels que spécifiés dans la JSR 133^ 
JooFlux utilise des instances de VolatileCallSite. Ainsi, toute modification effectuée sur un site d'ap- 
pel est visible par tous les threads qui souhaiteraient effectuer une invocation. A l'inverse, l'emploi de 
MutableCallSite est sujet à une mise en cache par un thread, et une modification d'un site d'appel n'est alors 
pas nécessairement immédiatement visible des autres threads. Ce choix a un impact potentiel sur les performances, 
principalement en cas de contention avec une écriture. Les résultats dépendent grandement de l'architecture maté- 
rielle utilisée et des tentatives d'optimisation du JIT. 

3.4. Piloter JooFlux pour remplacer à chaud des méthodes et injecter des aspects 

La couche de gestion de JooFlux utilse le registre de diverses façons via un agent JMX^jpour effectuer des requêtes. 
Cet agent offre les opérations distantes suivantes : 

1. remplacer les implémentations de méthode, et 

2. injecter un aspect avant ou après certains sites d'appel, et 

3. obtenir diverses métriques telles le nombre de sites d'appels gérés par JooFlux ou leur liste. 

À titre d'exemple, voyons l'interaction pour un remplacement de méthode via l'interface de l'agent JMX : 

void changeCallSiteTarget ( String methodType, 

String oldTarget, String newTarget) 



Le paramètre methodType spécifie le type d'invocation et prend pour valeur static, virtual interface ou spécial. 
Les 2 autres paramètres spécifient un identifiant de site d'appel à remplacer, et une référence de méthode pour la 
nouvelle cible. 



Before button handier replacement 




Figure 3 - Interaction via JMX avec une application modifiée par JooFlux. 

La Figure |3]expose une application avec un bouton à gauche et un texte à droite. En se connectant à l'agent JMX 
JooFlux via un outil comme j console, nous pouvons remplacer le gestionnaire d'événement de bouton de sorte 



2. JSR 133 : JavaTM Memory M odel and Thread Spécification — |http : / / jcp . orq/en/ j sr/detail?id=133 

3. Java Management Extensions : http : / / jcp . org/ about Java/communityprocess/ final / j sr003 / index3 . html 
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qu'au prochain clic, une image remplace le texte. Dans ce cas précis, nous avons utilisé les paramètres suivants 
pour l'opération changeCallSiteTarget de l'agent JMX : 

virtual, // virtual method 

f r/ insalyon/telecom/ joofluxt est /gui/ swit cher/ 

MyActionListener . counter Incrément : (MyActionListener ) void, // handler id 
f r/ insalyon/telecom/ joofluxt est /gui /swit cher / 

MyActionListener . pictureSwitch : ()V // our new handler 



Enfin, injecter un aspect via l'agent JMX se fait de façon similaire : 

void applyBef oreAspect ( String callSitesKey , 

String aspectClass, String aspectMethod) 

void applyAf terAspect ( String callSitesKey, 

String aspectClass, String aspectMethod) 



4. Comparaison expérimentale avec des plates-formes AOP et des langages dynamiques 

Pour valider notre approche, nous comparons les performances de la machine virtuelle Java avec notre agent 
JooFlux à d'autres approches effectuant également de la re-direction dynamique de méthodes : les plates-formes à 
aspects (section 4.1 1 et les langages de programmation dynamiques (sections 4.2J4.3 l. 



Toutes ces approches sont basées sur la machine virtuelle et ont été testées avec des micro- et des macro-jeux de 
tests sur un MacBook Pro 2,3 GHz Intel Core2 (i5), 4 Go 1333 MHz DDR3, avec Mac OS X Lion 10.7.4 (1 1E53) et 
l'OpenJDK Runtime Environment 1.7.O-ulO-bO6-2O12O9O60 Ces tests ont été renouvelés 10 fois pour constituer 
le jeu de résultats, sur lequel nous avons calculé les quartiles et les sur-coûts médians. 

4.1. Micro-tests et plates-formes AOP 

Nous comparons la fonctionnalité d'injection d'aspects de JooFlux avec deux plates-formes AOP : Aspectj[^] fïÔl et 
Byteman^ôï. Nous utilisons le calcul classique d'une fonction Fibonacci récursive (classicf ibo)[^]à laquelle 
nous injectons avant et/ou après un aspect vide - c.à.d. une re-direction d'appel vers une méthode vide. Le tableau[T] 
présente les résultats. 

Le temps d'exécution du bytecode généré par AspectJ est proche de celui de Java, seulement il tisse les aspects 
statiquement pendant la compilation et plus aucune modification ne peut être effectuée à l'exécution. Byteman 
permet l'injection d'aspects pendant l'exécution en déchargeant la classe et modifiant son bytecode pendant son 
rechargement. Cette technique dégrade significativement les performances et implique que toutes les optimisations 
JIT sont perdues. Le bytecode généré par JooFlux contient déjà les appels dynamiques, donc le coût de tissage 
d'un aspect est seulement le coût d'ajout d'un nouveau combinateur dans la chaîne d'un site d'appel, de recopier 
les arguments et de transférer la valeur de retour. En conservant la chaîne d'appel à peu près intacte, JooFlux 
sauvegarde les optimisations JIT. 

4.2. Micro-tests et langages dynamiques 

De nombreux langages de programmation proposent la re-direction dynamique de méthodes directement dans 
le langage, par exemple avec les APIs de réflexion. Pour tester la fonctionnalité de re-direction dynamique de 
méthodes de JooFlux, nous la comparons aux principaux langages dynamiques basés sur la machine virtuelle : 
Java|5 ClojureQ JRuby[^] Groovy[_[] Rhino JavaScript^] and Jython[j 

Nous testons la performance avec le même micro-jeu de test Fibonacci. Selon le langages de programmation, la 
fonction Fibonacci peut s'écrire de différentes manières : classicf ibo manipule des objets, f astf ibo ma- 
nipule des paramètres de type long, f astestf ibo manipule également des paramètres et une valeur résultat de 



4. OpenJDK Run time Environment 1.7.0-ul0-b06-20120906 : http : / /code . google . com/p/ open jdk-osx-build/| 

5. AspectJ 1.7.1 : |http : / /www, éclipse ■ org/aspect t7| 

6. Byteman 2.1.0 :]h"tt p : / / www, jboss . orq/byteman/ | 

7. Récursive Fibonacci : http : / /en . wikipedia . org/wlki/Recursion_ (computer_science) #Fibonacci 



8. Java 7 :|http : //docs . oracle . com/ javase / 7/docs/api/ 



Clojure I.4.U : http ://clojure.org 



10. JRuby 1.6.7.2 (-indy), 1.7.0.preview2 (+indy) : http : / / jruby . org 

11. Groovy 2.0.2 (-+indy) :| http : //groovy . cocTehaus . org| 



12. Rhino Javasc ript 1.7R4 :|https : / /developer . mozillâ. org/ en- US /docs /Rhino 



13. Jython 2.5.3 : http : //www. python . org 
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Plat. Exec. 


Tissage 


Impl. 


Ql-min 


Q2-25% 


Q3-median 


Q4-75% 


Q5-max 


Sur-coût 


JVM 




classicfibo 


611 


613 


615 


616 


636 




JVM + 

AspecU 


compilation 


classicfibo 
+ aspect avant 


609 


613 


620 


621 


650 


+0,8% 


classicribo 
+ aspect après 


609 


611 


620 


621 


693 


+0,8% 


classicfibo 
+ aspect avant 
& aspect après 


OUV 


fil 1 


Aon 


ozz 


"7 17 


tU,o /c 


JVM + 
Agent JooFlux 


exécution 


classicfibo 
+ aspect avant 


3007 


3028 


3051 


3070 


3525 


+396% 


classicribo 
+ aspect après 


1269 


1273 


1280 


1295 


1356 


+108% 


classicfibo 
+ aspect avant 
& aspect après 


3804 


3830 


3861 


3893 


3950 


+528% 


JVM + 

Byteman 


exécution 


classicfibo 
+ aspect avant 


79309 


84998 


85371 


85695 


86397 


+13781% 


classicfibo 
+ aspect après 


82561 


82780 


82911 


83040 


83406 


+13381% 


classicfibo 
+ aspect avant 
& aspect après 


179984 


188088 


188187 


188321 


188971 


+30499% 



Table 1 - Fibo(40) micro-test pour les plates-formes AOP (en ms) 



type long, et finalement ref lectivef ibo utilise TAPI de réflexion pour l'invocation de méthode. Ces diffé- 
rentes implémentations ont leur importance car elles influencent le bytecode généré et donc les performances. Les 
résultats pour Java sont présentés dans le tableau[2] Le sur-coût de JooFlux est insignifiant pour classicfibo 
et présente un facteur de ralentissement de 2 pour ref lectivef ibo. Cette mise en œuvre de Fibonacci est en 
effet notre pire cas, car la machine virtuelle peut difficilement effectuer des inclusions de code (Mining). 



Lang. Prog. 


Plat. Exec. 


Impl. 


Ql-min 


Q2-25% 


Q3-median 


Q4-75% 


Q5-max 


Sur-coût 


Java 


JVM 


classicfibo 


611 


613 


615 


616 


636 




reflectivefibo 


1758 


1762 


1782 


1803 


4121 




Java 


JVM + 

Agent JooFlux 


classicfibo 


611 


613 


616 


618 


690 


+0,001% 


reflectivefibo 


3668 


3686 


3717 


3743 


4273 


+108% 



Table 2 - Fibo(40) micro-test pour le langage Java (en ms) 



Les résultats pour les autres langages de programmation sont présentés dans le tableau [3] Les sur-coûts pour 
classicfibo, fastf ibo et fastestf ibo sont comparés à ceux de JVM+JooFlux classicfibo. Les 
implantations de reflectivefibo sont toujours comparées à celle de JVM+JooFlux reflectivefibo. 
Même si l'implémentation fortement typée en Clojure présente seulement un facteur de ralentissement de 1.2-1.4, 
la plupart des autres langages sont de 3 à 18 fois plus lents que notre prototype JooFlux. JRuby et Groovy proposent 
des versions bêta utilisant l'opcode invokedynamic (+indy, chiffres en italiques dans le tableau^ mais même 
s'ils gagnent un facteur 1.5-2, ils restent significativement plus lents que Java+JooFlux. 

Pour les micro-tests, que ce soit AOP ou langages dynamiques, notre agent JooFlux réécrit le bytecode en 75- 
100ms pour une transformation de 2 classes (Fibonacci et InvokeBootstrap - la classe de bootstrap est 
elle-même dynamique) et 1 méthode (classicfibo). Ce délai raisonnable est introduit avant le démarrage de 
l'application et reste comparable aux délais de lancement des autres plates-formes. 

4.3. Macro-tests de calculs et réécritures intensifs 

Pour tester plus intensément la redirection dynamique de méthodes avec JooFlux, nous avons utilisé 3 macro-jeux 
de tests : 

1. SCImark 2.00: 

SciMark 2.0 est un jeu de tests en Java pour le calcul scientifique et numérique, assez 
consommateur en CPU et mémoire. Il effectue plusieurs types de calcul et retourne un score composite en 
Mflops. 



14. SCImark 2.0: 



http : / /math . nist . gov/ scimark2/ 
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Lang. Prog. 


Plat. Exec. 


Impl. 


Ql-min 


Q2-25% 


Q3-median 


Q4-75% 


Q5-max 


JooFlux Diff 


Clojure 


JVM 




722 


732 


734 


740 


742 


+19% 


fastfibo 


859 


862 


864 


875 


892 


+40% 


classicfibo 


4105 


41 18 


4171 


4265 


4326 


+577% 


JRuby 


JVM 

(+indy) 


classicfibo 


6290 
(3982) 


6333 
(4006) 


6382 
(4020) 


6486 
(4069) 


7043 
(4323) 


+936% 

( ^ J J IV j 


reflectivefibo 


10226 

( / J4J ) 


12020 

( / JOl ) 


12060 

{ / JOl j 


12076 
(7021) 


12288 

(//il) 


+224% 
{ + l\J°t /c) 


Groovy 


JVM 

f +indy) 


fastestfibo 


(3061) 


1 1RS 

(3077) 


1394 
(3092) 


1401 

(3150) 


1417 
(3165) 


+126% 

(+402%,) 


fastfibo 


2709 
(2513) 


2721 
(2519) 


2725 
(2528) 


2749 
(2540) 


2766 
(2583) 


+342% 
f+3i0%j 


classicfibo 


8660 
(4461) 


8691 

(4488) 


8716 
(4522) 


8726 
(4584) 


9066 
(4656) 


+1315% 

(+6i4%j 


reflexivefibo 


57734 
(8366 


57892 
(8378) 


58009 
(8386) 


58182 
(8405) 


58364 
(8697) 


+1460% 
(+725%) 


Javascript 


JVM 


classicfibo 


9052 


9208 


11275 


11441 


11764 


+1730% 


Jython 


JVM 


classicfibo 


29053 


29258 


29675 


30202 


31871 


+4717% 



TABLE 3 - Fibo(40) micro-tests pour les langages de programmation basés sur la JVM (en ms) 



2. Un compteur de mots pouvant s'exécuter en parallèle avec Fork/Join ifïôll : ce compteur stresse particulière- 
ment la mémoire et les entrées/sorties en comptant le nombre de mots dans chaque fichier contenu dans une 
arborescence de fichiers. 

3. L'environnement d'exécution du langage Clojure au-dessus de JooFlux : nous avons utilisé le langage de 
programmation Clojure dont l'implantation est entièrement écrite en Java pour avoir un jeu de tests effectuant 
un nombre massif de réécritures de bytecode. 

SCImark 2.0 

Ce jeu de tests effectue des transformations de Fourier {Fast Fourier Transformations, FFT), résout des équations 
de Laplace (Jacobi Successive Over- relaxation, SOR), approxime la valeur de n (Monte Carlo intégration, MC), 
multiplie des matrices (Sparse matrix multiply, SM), effectue des factorisations de matrices denses (dense LU 
matrix facto rization, LU) et calcule finalement un score composé (Composite Score, CS). Ces différents calculs 
sont réalisés sur un petit ou un grand jeu de données. 

Les performances avec et sans JooFlux sont présentées dans le tableau [4] La plupart des calculs présentent des 
sur-coûts ou gains marginaux, excepté pour l'intégration Monte Carlo qui perd 20% en performance. L'algorithme 
Monte Carlo utilise des fonctions synchronisées et de l'inclusion de fonctions (cf documentation de SCImark) et 
les fonctions synchronisés n'impactant pas les performances (cf le macro-test du comptage parallèle ci-après), la 
perte provient de difficultés d'optimisations JIT du fait de l'inclusion de fonctions. 





FFT 


SOR 


MC 


SM 


LU 


CS 


2io 


£20 


10 2 xl0 2 


10 3 xl0 3 




N=10 3 
nz=5.10 3 


N=10 s 
nz^lO 6 


10 2 xl0 2 


10 3 xl0 3 


Small 


Large 


JVM 


827 


178,7 


1196,5 


1077,6 


635,4 


1180,8 


1227,8 


2467,8 


1490,2 


1261,5 


915,4 


JVM + 
JooFlux 


824,3 


178,5 


1193,2 


1080,3 


507,2 


1172,9 


1249,5 


2325,9 


1489,7 


1204,9 


900,2 


Perf. 


-0,3% 


-0,1% 


-0,3% 


+0,3% 


-20% 


-0,7% 


+1,8% 


-5,8% 


-0,03% 


-4,5% 


-1,7% 



Table 4 - SCImark2.0 macro-test (in Mflops) 



Compteur parallèle de mots dans les fichiers 

Nous avons appliqué le compteur de mots sur l'arborescence de fichiers source de la machine virtuelle 
HotSpot (2.1 3 files) avec un processus mono-thread et avec un processus à 2-threads sur 2 cœurs du CPU. 
Comme le montre le tableau [5] de manière surprenante, le bytecode modifié par JooFlux améliore les perfor- 
mances. Ce résultat montre bien que les appels synchronisés de méthodes ne sont pas affectés par l'indirection 
invokedynami c et que le JIT peut même en bénéficier et parfaitement trouver de meilleures inclusions de code. 
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Plat. Exec. 


Impl. 


Ql-min 


Q2-25% 


Q3-median 


Q4-75% 


Q5-max 


Sur-coût 


JVM 


wordcounter 
1 thread 


3707 


3727 


3733 


3752 


4769 




wordcounter 
fork/join 2 threads 


1826 


1934 


2161 


2235 


5949 




JVM + 
Agent JooFlux 


wordcounter 
1 thread 


3634 


3646 


3658 


3689 


4829 


-2% 


wordcounter 
fork/join 2 threads 


1825 


1916 


2029 


2070 


2407 


-6% 



Table 5 - Macro-test du compteur parallèle de mots pour Java (en ms) 
Clojure au-dessus de JooFlux 

L'environnement d'exécution du langage Clojure est une application Java assez conséquente (3.1 3 classes). Nous 
l'avons utilisé comme jeu de tests pour appliquer des réécritures et interceptions massives. Nous avons ré-exécuté 
le micro-test Fibonacci, mais cette fois avec une totale réécriture du bytecode de Clojure : 1325 classes trans- 
formées, 26866 méthodes transformées et 19646 interceptions initiales de méthodes. Nous ne traçons pas toutes 
les interceptions de méthodes - seulement la première lors du passage par le registre - car les outils de traces en 



continu sont bien connus pour ralentir dramatiquement les performances. Le tableau 6 présente les résultats. 
Le sur-coût introduit est toujours insignifiant par rapport au temps d'exécution total. Nous pouvons donc dire que 
rendre le langage Clojure dynamique est intéressant^ avec un coût réduit à l'exécution. Un surcoût de 4s est par 
contre introduit pour la transformation du bytecode. Celui-ci n'est plus négligeable mais il s'applique seulement 
une fois au chargement, ne change en rien les performances pendant l'exécution et est un prix raisonnable pour 
rendre l'application entièrement dynamique. 



Lang. Prog. 


Plat. Exec. 


Impl. 


Ql-min 


Q2-25% 


Q3-median 


Q4-75% 


Q5-max 


Sur-coût 


Clojure 


JVM 


fastestfibo 


701 


702 


704 


708 


717 




fastfibo 


839 


845 


848 


851 


855 




classicfibo 


3969 


3978 


3984 


4010 


4093 




Clojure 


JVM + 
Agent JooFlux 


fastestfibo 


695 


699 


702 


704 


713 


-0,3% 


fastfibo 


856 


861 


864 


868 


891 


+1,9% 


classicfibo 


3957 


3969 


3980 


4002 


4069 


-0,1% 



Table 6 - Fibo(40) en Clojure au dessus de la plate-forme JVM+ JooFlux (en ms) 



5. État de l'art 
Programmation par aspects 

De nombreux travaux s'attaquent à la conception et l'implantation de la programmation par aspects. AspectJ est 
une plate-forme bien connue qui comprend un langage d'aspect et un compilateur [10|. Bien que statique, elle 
permet des transformations et tissages de bytecode efficaces, et offre un langage à granularité fine pour définir les 
points de coupe. Javassist est une autre plate-forme AOP statique en Java 0. Certains travaux se concentrent sur le 
tissage dynamique d'aspects ifTÏÏirPTI . JBoss Byteman est particulièrement intéressant car il propose des règles de 
type ECA (Événement-Condition- Action) |6|. Par le biais d'un agent Java qui peut être appliqué à un programme 
en cours d'exécution, il peut appliquer ou retirer ces règles dynamiquement. Les travaux de |4 | illustrent le fait que 
fournir une machine virtuelle modifiée est une solution permettant d'offrir un panorama complet d'opérations de 
modifications dynamiques d'applications Java. Ces résultats concordent avec |24|. 

Machines virtuelles 

Le domaine des machines virtuelles ne manque pas de problématiques. La JVM est une plate-forme attractive 
pour les travaux de recherche étant donné sa spécification ouverte |[Ï2l . De nombreux travaux visent à en amé- 
liorer les performances lfÏ4l [ÏTl l8l. La conception de la JVM possède un biais initial qui favorise les langages 

15. Fibo(40) en Clojure n'a pas exactement les mêmes performances dans le tableau|ô]et le tableau|3] Pour permettre une bonne comparaison, 
nous avons préféré présenter les résultats de Clojure+JVM et ceux de Clojure+JVM+ JooFlux issus du même test. 

16. "Why Clojure doesn't need mvokedynamic, but it might be nice" |http : //blog . f ogus .me 72011/10/14 / | 
Iwhy-clo jure-doesnt-need- invokedynamic-but-it-might-be-nice/l 
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statiques fortement typés. L'intérêt croissant envers les langages dynamiques sur la JVM a amené l'apparition de 
invokedynamic et de l'API de support java . lang . invoke Ifï9ll . Ceci facilite l'implémentation de ces lan- 
gages tout en donnant des points d'entrée pour les optimisations adaptatives du JIT [21|. De nouveaux usages de 
invokedynamic commencent à apparaître [ 1 1, et le support des lambdas dans Java 8 devrait s'appuyer dessusP] 




Mise à jour dynamique de logiciels 

La fonctionnalité de mise à jour dynamique de logiciel n'est pas une nouvelle idée et a été longuement étudiée par 
de nombreux travaux [7 , 9|. Les techniques mises en œuvre dépendent fortement du langage de programmation ou 
de la plate-forme d'exécution ciblée. Des patchs dynamiques peuvent être appliqués au niveau du système d'exploi- 
tation comme dans et lfT5ll . Plus proche de la machine virtuelle Java, les travaux de [25 1 permettent de modifier le 
code Java à l'exécution en supportant l'ajout ou le retrait de champs et méthodes. Cette approche requiert toutefois 
une machine virtuelle modifiée. Les mêmes auteurs utilisent cette même machine virtuelle modifiée et appliquent 
une programmation par aspects dynamique dans l24l . Il est important également de mentionner que la redéfinition 
des classes passe par un rechargement dans la machine virtuelle. C'est également le cas dans des approches comme 
Byteman [6 1 qui travaille avec des définitions stables des classes, les recharge et perd les optimisations accumulées 
par le JIT. D'autres approches pour la mise à jour dynamique utilisent des machines virtuelles modifiées. JnJVM 
offre une machine virtuelle à composants dans laquelle non seulement des aspects peuvent être injectés dynami- 
quement pour modifier les applications, mais la machine virtuelle elle-même est sujette aux modifications 11221 . 
JVolve est une autre machine virtuelle, dérivée de Jikes RVM, et qui supporte l'évolution d'applications [20|. 



6. Conclusions et perspectives 

6.1. Conclusion 

Cet article a présenté JooFlux, un agent JVM qui permet à la fois le remplacement dynamique d'implémentations 
de méthodes et l'injection d'aspects. Par rapport aux approches existantes, JooFlux prend un chemin original 
en utilisant invokedynamic. Les jeux de tests montrent que le sur-coût de JooFlux est négligeable pour les 
invocations de méthodes, et modeste pour les aspects. Dans tous les cas, JooFlux offre de meilleures performances 
que des approches similaires tels des outils d'AOP ou des langages dynamiques. De plus, JooFlux ne nécessite 
pas de rechargement de définitions de classes, ce qui préserve les optimisations du JIT pour tous les sites d'appel 
non concernés. Il ne nécessite pas non plus de JVM ad-hoc. La fine couche d'indirection introduite ne demande 
pas de résolution d'entrée de tableau associatif ou de garde, ce qui aide grandement l'optimisation adaptative. 
Enfin, JooFlux opère de façon transparente au niveau des sites d'appel, et il ne nécessite pas de langage dédié pour 
spécifier les changements. 

6.2. Perspectives 

JooFlux est pour l'heure un prototype de recherche qui démontre comment invokedynamic peut être utilisé à 
d'autres fin que la mise en oeuvre d'un langage dynamique sur la JVM. Tandis qu'il valide notre approche sur des 
applicatifs de taille modeste, il reste à travailler à son usage sur un plus large panel d'applications pour la JVM. 
Au vu des performances prometteuses de JooFlux, notre volonté est poursuivre l'étude de ses applications dans 
des contextes spécialisés tels le contrôle de ressources, les architectures multi-tenantes ou encore les systèmes 
modulaires dynamiques pour Y Internet des objets, sans devoir passer par des abstractions ou plates-formes telles 
OSGi[^] Si nos expérimentations ont pour le moment été effectuée avec Hotspot, nous envisageons de développer 
les études sur d'autres machines virtuelles Java supportant invokedynamic. MaxineVM est à ce titre une cible 
intéressante car elle est développée en Java [23 1. Nous pourrions ainsi étudier l'injection d'aspects et le rempla- 
cement dynamique de code au sein même d'une machine virtuelle et de ses composants tels le ramasse-miettes 
mémoire ou l'interpréteur, de façon analogue aux travaux menés dans l22l . Sur le plan des fonctionnalités, nous 
souhaitons ajouter le support des modifications multiples de manière transactionnelle. Il serait également intéres- 
sant de pouvoir vérifier statiquement l'applicabilité des modifications avant de les opérer. 



17. 


http 


: / / open j dk . j ava . 


net /project s /lambda/ 


18. 


http: 


/ /www . osgi . org/ 
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6.3. Disponibilité 

JooFlux est disponible sous la forme d'un projet open source [https : / /github . com/dynamid/ joof lux| 
Il est mis à disposition selon les termes de la Mozilla Public License Version 2.0p*| La version du prototype de Joo- 
Flux utilisée pour la rédaction de cet article correspond au tag Git annoté rO. Nous encourageons la communauté 
des chercheurs et praticiens à nous remonter tout problème, ainsi qu'à contribuer des correctifs et améliorations. 
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